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Abstract 


A  relational  associative  processor  called  RAP  has  been  designed  to 
provide  hardware  support  for  the  use  and  manipulation  of  a  relational  data 
base.  In  this  paper,  we  describe  the  relational  operations  provided  by 
the  RAP  hardware,  and  devise  a  representative  approach  to  providing  the 
same  relational  operations  with  conventional  software  and  hardware. 

Analytic  models  are  constructed  for  both  RAP  and  the  conventional  system. 

All  simplifying  assumptions  are  made  to  favor  the  conventional  system. 

The  execution  times  of  several  of  the  operations  are  shown  to  be  improved 
with  RAP  by  several  orders  of  magnitude. 

Keywords:  DATA  BASE  MACHINES,  ASSOCIATIVE  PROCESSORS,  PERFORMANCE  EVALUATION, 
RELATIONAL  DATA  BASES. 
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I.  Introduction 

In  order  to  avoid  the  difficulties  of  using  conventional 
software  and  hardware  to  implement  a  relational  data  base 
management  system,  a  relational  associative  processor  called  BAP 
has  beon  designed  and  a  prototype  is  being  built.  RAP  has  a 
cellular  architecture  where  each  cell  uses  a  sequential 
circulating  memory  such  as  a  charge-coupled  device,  bubble 
memory,  or  track  of  a  disk  or  drum.  The  logic  associated  with 
each  cell  supports  arithmetic,  comparison,  and  input-output 
operations.  Software  running  on  a  conventional  computer  provides 
support  functions.  RAP  can  be  considered  to  be  a  ''backend"  data 
management  processor  for  a  large  conventional  computer. 

The  purpose  of  this  paper  is  to  present  the  results  of  a 
comparative  performance  study  between  RAP  and  a  conventionally 
supported  data  base  management  system.  We  begin  with  a  brief 
overview  of  the  RAP  system,  then  we  describe  a  set  of  operations 
fcr  using  and  manipulating  a  relational  data  base.  Analytic 
models  are  then  used  to  quantify  the  times  required  by  the 
operations  in  both  the  RAP  system  and  a  conventional  system. 
Finally,  for  each  of  the  operations,  a  comparison  is  made  by 
graphing  the  ratio  of  service  times  in  the  two  systems  while 
varying  various  parameters  representing  hardware  design 
alternatives  and  the  manner  in  which  the  data  base  is  used. 

We  will  attempt  only  first-order  accuracy  in  the  analytic 
models  derived  here.  Due  to  the  massive  performance  differences 
that  will  result  from  the  comparison,  any  aspect  that  causes  less 
than  a  factor  of  two  difference  ir  timing  can  be  ignored  without 
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noticeably  altering  the  results.  We  will  further  assume  that 
both  systems  store  normalized  relations  directly.  The  physical 
organization  will  closely  reflect  the  logical  organization.  No 
attempt  will  be  made  at  optimization  of  query  processing.  Multi¬ 
attribute  Boolean  qualification  criteria  in  queries  will  be 
evaluated  using  all  the  attributes  involved  in  the  criteria. 

II.  Description  of  BAP 

Because  the  BAP  system  is  thoroughly  documented  elsewhere 
[1  ,2,3,4],  we  will  present  here  only  an  overview  of  those  aspects 
of  the  system  design  that  most  affect  performance.  BAP  stores 
data  as  relations  [5,6].  In  the  remainder  of  the  paper,  we  will 
assume  familiarity  with  the  basic  terminology  dealing  with 
relational  data  bases  [6].  While  there  are  some  limitations  on 
the  sizes  and  numbers  of  tuples  and  attributes  in  BAP  relations, 
these  are  usually  not  restrictive  and  need  not  be  brought  into 
this  performance  study.  Therefore,  in  the  analysis,  we  will 
assume  that  the  data  base  is  contained  in  the  BAP  memory.  System 
performance  in  cases  where  data  base  size  is  larger  than  BAP 
memory  has  been  considered  in  a  separate  study  [4].  Each 
relation  is  augmented  by  four  additional  one-bit  domains.  These 
will  be  called  mark  bits  and  will  be  used  for  temporarily  or 
semi-permanently  denoting  subsets  of  the  tuples  in  a  relation. 

The  initial  implementation  of  BAP  will  be  on  a  disk-like 
device,  but  the  same  architecture  is  feasible  on  many  other 
current  and  anticipated  pseudo-random  access  bulk  memory  devices. 
B£P  consists  of  a  large  number  of  cells  (the  alternative  term 


5 


track  will  imply  a  disk-like  implementation)  each  with  its  own 
read  mechanism,  write  mechanism,  and  logic-  Each  cell  is  devoted 
tc  storing  tuples  of  a  specified  relation.  However,  it  may  take 
several  cells  to  store  all  the  tuples  of  a  large  relation.  The 
number  of  tuples  that  can  be  stored  in  one  cell  varies  from 
relation  to  relation  depending  on  the  number  and  sizes  of 
attributes  in  the  relation.  (There  will  be  on  the  order  of  1000 
tuples  per  cell.) 

The  write  mechanism  follows  the  read  mechanism  as  the  memory 
circulates  on  each  cell  at  a  distance  proportional  to  the  length 
of  buffer  associated  with  the  cell.  The  buffer  is  a  shift- 
register,  whose  length  can  be  designed  to  hold  any  reasonably 
sized  tuple.  The  data  is  read  and  passed  through  the  buffer 
before  being  written  back  into  place.  During  it's  passage 
through  the  buffer,  the  data  can  be  modified.  The  buffer  also 
provides  a  convenient  means  of  automatic  dynamic  garbage 
collection.  When  a  tuple  is  deleted,  all  tuples  following  it  on 
the  cell  are  advanced  by  effectively  '‘short-circuiting"  an 
appropriate  portion  of  the  buffer.  When  a  tuple  is  inserted,  it 
is  positioned  immediately  following  the  last  tuple  currently  on 
the  cell. 

The  logic  associated  with  each  cell  provides  arithmetic 
operations  and  flexible  comparison  operations.  Each  cell  has 
several  comparator  units,  each  of  which  independently  examines  a 
particular  attribute  and  compares  its  value  with  another 
specified  value.  Throughout  the  paper,  the  number  of  comparator 
units  per  cell,  which  is  a  RAP  design  parameter,  will  be  denoted 
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by  k.  The  results  of  individual  comparator  units  can  be  combined 
through  hardware  Boolean  operations. 

RAP  relies  on  a  general  purpose  computer  for  a  number  of 
support  functions.  The  support  processor  acquires  user  queries 
expressed  in  high-level  query  languages  either  interactively  or 
through  a  host  language.  It  compiles  the  queries  into  RAP 
primitives,  which  are  then  passed  to  the  RAP  controller.  The 
support  processor  records  relation  names,  domain  names  and  data 
value  encoding  tables.  Finally,  it  assures  data  base  security 
and  integrity  and  also  schedules  the  execution  of  queries  by  RAP. 

III.  Relational  Operations  As  Supported  By  RAP 

The  operations  required  for  using  and  manipulating  simple 
normalized  relations,  such  as  those  stored  by  RAP,  include  the 
following  [ 6 ]: 

1)  selection  of  tuples  satisfying  some  criterion, 

2)  modification  cf  selected  tuples, 

3)  deletion  of  selected  tuples, 

4)  addition  of  tuples, 

5)  computation  of  functions  over  sets  of  selected  tuples, 

6)  retrieval  of  selected  tuples  (output  operation), 

7)  projection  on  selected  attributes  of  a  relation, 

8)  implicit  join  of  two  relations  on  a  common  attribute. 

Implicit  join  has  been  called  restriction,  composition,  and 
mapping  elsewhere.  It  involves  two  relations  that  each  possess 
attributes  (known  as  join  attributes)  whose  values  come  from  a 
common  domain.  Selected  tuples  from  the  first  relation  indicate 
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some  subset  of  values  for  the  join  attribute  of  the  first 
relation.  The  implicit  join  is  accomplished  by  identifying  those 
tuples  in  the  second  relation  that  have  join  attribute  values 
that  are  in  the  same  subset.  It  has  been  argued  that  the 
implicit  join  provides  the  power  of  a  natural  join  while  avoiding 
seme  of  its  dangers  (e.g.  the  connection  trap)  [7].  A  natural 
join  can  be  synthesized  by  doing  repeated  implicit  joins  on 
single  values,  retrieving  the  tuples  from  both  relations  and 
assembling  the  results  in  the  support  processor. 

While  these  operations  reguire  complex  software  when  provided 
on  conventional  hardware,  the  basic  instruction  set  of  RAP 
provides  the  operations  directly.  Most  RAP  instructions  include 
a  qualification  expression  to  specify  those  tuples  to  be  dealt 
with.  The  qualification  expression  is  a  Boolean  disjunctive  or 
conjunctive  expression  of  simple  conditions,  each  of  which  tests 
an  attribute  value  (possibly  a  mark  bit  attribute)  against  a 
specified  constant.  The  test  may  be  for  equality  or  for 
inequality  (e.g.  greater  than). 

The  complexity  of  Boolean  expressions  for  use  in 
qualification  is  highly  variable.  Three  characteristics  of  their 
structure  are  significant  with  respect  to  the  efficiency  of  the 
evaluation : 

a)  number  of  simple  conditions, 

b)  proportion  of  simple  conditions  involving  tests  for 
equality, 

c)  the  number  of  conjunctive  (disjunctive)  clauses  in  the 
disjunctive  (conjunctive)  normal  form  representation. 
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The  number  of  simple  conditions  in  the  qualification  criterion 
affects  the  evaluation  time  in  both  RAP  and  the  conventional 
system-  It  will  be  denoted  by  Cl  (for  "criterion  length") .  The 
proportion  of  tests  for  equality  and  the  number  of  clauses  impact 
respectively  a  conventional  system  and  the  RAP  system  (as  will  be 
demonstrated  later) .  We  will  use  "equality  test"  and  "inequality 
test"  to  refer  to  the  extreme  cases  of  all  tests  or  no  tests 
being  for  equality.  "Single-clause"  and  "multi-clause"  will 
distinguish  situations  with  simple  conjunctive  forms  (AND  of 
simple  conditions)  and  disjunctive  forms  (OR  of  simple 
conditions)  from  more  complex  situations.  Due  to  the  paucity  of 
experimental  data  on  qualification  conditions  used  in  practice, 
we  will  look  only  at  these  extremes  of  the  qualification 
expression  characteristics. 

Eelow  we  enumerate  some  of  the  basic  RAP  instructions  and 
indicate  their  purposes.  More  detail  on  these  and  other 
operations  is  provided  elsewhere  [1,3]. 

1.  MARK 

The  MARK  instruction  is  used  for  selection.  In  a  specified 
relation,  it  sets  mark  bits  in  each  tuple  that  satisfies  a 
specified  qualification  expression,  which  may  involve  constants, 
attribute  values,  or  values  in  RAP  registers. 

2.  COUNT,  SUM,  MAX,  MIN,  AVERAGE 

These  functions  can  be  applied  to  any  numeric  (also  non¬ 
numeric  for  COUNT)  attribute  of  a  selected  set  of  tuples.  The 
result  is  deposited  in  a  RAP  register  for  use  directly  or  in 
later  qualification  expression.  Selection  of  tuples  and  the 
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requested  calculation  take  place  concurrently  during  the 
execution  cf  the  instructions. 

3.  REPLACE,  ADD,  SOB,  MUL,  DIV 

The  values  of  a  specified  attribute  of  a  set  of  selected 
tuples  can  be  replaced  using  the  REPLACE  operation  or  modified 
using  the  operations  ADD,  SUB,  MUL,  or  DIV.  The  values  used  for 
replacement  or  as  arithmetic  operands  may  be  constants,  other 
domain  values  (except  in  DIV) ,  or  the  contents  of  RAP  registers. 
The  operations  on  the  selected  tuples  take  place  as  the  tuples 
pass  through  the  buffer  associated  with  the  cell. 

4.  DELETE,  INSERT 

Tuples  of  a  relation  may  be  deleted  by  DELETE  or  added  by 
INSERT.  (Eulk  insertions  are  handled  in  a  different  way  [1].) 

5.  READ 

The  READ  operation  causes  a  selected  set  of  tuples  to  be 
transmitted  to  the  support  processor  either  for  output  to  users 
or  for  further  processing  by  host-language  programs. 

6.  GET_FIRST_MARK 

This  operation  is  more  complex.  In  some  relation,  the  first 
tuple  with  a  specified  mark  bit  on  is  located,  and  one  of  its 
domain  values  is  used  to  do  a  new  marking  on  the  entire  relation 
(using  a  different  mark  bit) .  Finally,  the  tuple  originally 
selected  has  its  mark  bit  reset,  so  it  will  be  bypassed  by  the 
next  execution  of  the  same  GET_FIRST_MARK  instruction.  This 
instruction  is  used  to  do  projection,  grouping  [9]  and  free- 
variable  [7]  gueries. 
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7.  CROSS_MARK,  CRS_COND_MARK 

These  instructions  use  the  marking  and  data  on  one  relation 
as  the  basis  for  marking  another  relation.  They  are  used  to 
accomplish  an  implicit  join  operation. 

8.  TEST,  EC 

The  TEST  instruction,  together  with  the  conditional  branch 
instruction  (BC) ,  allows  controlled  iteration.  Iteration  is 
required  in  doing  projections  and  in  synthesizing  natural  joins, 
as  well  as  in  updates  involving  more  than  one  arithmetic 
operation . 

Most  of  the  instructions  described  above  require  one  RAP 
revolution  for  execution.  The  exceptions  are  AVERAGE,  which 
requires  two  or  three  revolutions,  TEST  and  BC,  which  require  a 
negligible  amount  of  time,  and  READ,  CROSS_MARK,  and 
CRS_COND_MARK.  CFOSS_MARK  requires  1+#MT/k+#C  revolutions  where 
k  is  the  number  of  comparator  units  in  each  cell,  and  #MT  and  #C 
are  respectively  the  number  of  tuples  marked  in  the  source 
relation  and  the  number  of  cells  occupied  by  marked  tuples. 
CRS_CCND_MARK  requires  one  more  revolution  than  CROSS_MARK. 
Depending  on  the  extent  of  the  source  relation's  marking,  these 
instructions  may  require  several  revolutions. 

Since  READ  can  transmit  only  one  tuple  at  a  time  to  the 
support  processor,  the  maximum  number  of  selected  tuples  at  any 
single  angular  position  on  RAP  determines  the  number  of 
revolutions  required  to  complete  the  instruction.  Naturally, 
this  expected  maximum  number  of  tuples  at  any  sinqle  relative 
tuple  position  depends  on  the  number  of  cells  (#C)  occupied  by 


the  relation,  the  number  of  tuple  positions  per  cell  (#P)  ,  and 
the  fraction  of  the  #C  times  #P  tuple  positions  that  hold  tuples 
selected  for  readout  (F)  .  Denoting  the  expected  maximum 
collision  length  by  READOUT (F),  figure  1  shows  READOUT  (F)  as  F 
varies  from  zero  to  one.  READOUT (F)  ranges  from  1  to  #C  as  F 
increases.  The  curve  is  a  close  approximation  for  any  situation 
in  which  #P>>#C>>1.  This  situation  is  expected  to  hold  in  most 
applications  of  RAP. 

In  concluding  this  section,  we  will  establish  timing  formulae 
for  two  basic  RAP  activities.  The  number  of  RAP  revolutions 
required  to  determine  which  tuples  satisfy  a  given  qualification 
is  denoted  by: 

for  single-clause  qualification 
for  a  multi-clause  qualification 
expression  is  a  simple  conjunction  or 
disjunction,  k  simple  conditions  can  be  processed  in  each  RAP 
revolution  since  there  are  k  comparator  units  on  each  cell.  In 
the  worst  case,  at  least  two  terms  will  be  processed  in  each 
revolution  (e.g.,  a  disjunctive  normal  form  with  every 
conjunction  having  two  single  conditions) . 

A  selection  operation  on  RAP  consists  of  evaluating  a 
qualification  expression  and  setting  mark  bits  in  tuples  that 
satisfy  the  qualification.  The  average  time  to  do  a  selection 
operation  on  RAP  is  given  by: 


QEVRAP  = 


[CL/k| 
[_CL/2  +  ij 


When  the  qualification 


SEIRAP 


(.5  +  QEVRAP) *RAPRTIME. 


Figure  1  RAP  read-out  time 


EXPECTED  PERCENTAGE  OF  ELIGIBLE  TUPLES 
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There  is  an  initial  rotational  delay  of  half  a  BAP  memory 
revolution  on  average,  followed  by  QEVBAP  revolutions  for 
qualification  evaluation  and  marking.  RAPETIME  is  the  rotation 
time  of  the  RAP  memory. 

Having  developed  this  expression  for  SELRAP,  we  proceed  in 
the  next  section  to  develop  a  corresponding  expression  for 
selection  in  the  conventional  system.  In  section  V,  these  will 
be  used  as  part  of  the  basis  for  comparing  the  two  systems. 

IV.  Relational  Operations  As  Supported  On  Conventional  Hardware 

When  a  relational  data  base  management  system  is  supported  on 
conventional  disk  or  drum  memories,  there  is  wide  latitude  in 
choosing  an  approach  for  providing  fast  data  access  paths  in 
software.  For  our  purposes  here,  we  choose  the  approach  of 
providing  inverted  lists  on  selected  attributes  of  each  relation. 
This  approach  is  generally  accepted  as  being  at  least  comparable 
in  efficiency  to  any  alternative  method  for  arbitrary  Eoolean 
selections  [8,9,10]. 

An  inverted  file  for  a  specific  attribute  in  a  relation 
consists  of  a  record  for  each  value  of  the  attribute  that  occurs 
in  the  relation.  The  record  for  a  particular  attribute  value 
contains  a  list  of  record  positions  in  a  corresponding  data  file 
to  indicate  records  representing  tuples  in  which  the  attribute 
value  occurs.  Each  record  of  an  inverted  file  is  known  as  an 
inverted  list.  The  position  numbers  within  each  list  are  kept  in 
ascending  order  to  facilitate  the  intersection  and  merge 
operations  necessitated  during  qualification  evaluation. 
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In  the  data  portion  of  the  file,  tuples  will  be  stored  as 
records  in  directly  addressed  files.  A  record  is  uniquely 
specified  by  a  file  name  and  a  relative  position  within  the  file. 
Both  the  data  records  and  the  inverted  list  records  are  blocked 
in  order  to  reduce  the  input-output  overhead  in  reading  them 
sequentially. 

The  inverted  lists  for  selected  attributes  of  each  relation 
will  be  stored  in  a  sequential  (ordered)  file  with  a  multi-level 
hierarchical  directory  (i.e.,  indexed  sequential  organization). 
The  purpose  of  the  directory  is  to  provide  fast  access  to  the 
inverted  list  for  any  specific  attribute  value.  We  will  assume 
that  all  levels  of  the  directory  except  the  lowest  are  contained 
in  main  memory.  The  lowest  level,  called  the  track  index,  will 
reside  on  the  device  containing  the  inverted  files. 

Sequential  retrieval  of  data  in  the  conventional  system  takes 
on  average  an  amount  of  time  given  by: 

SEQRET(N)  =  (.5  +  N)  UPTIME 

where  N  is  the  number  of  tracks  of  data  being  retrieved  and  8 TIME 
is  the  rotation  time  of  the  disk  on  which  the  data  and  inverted 
lists  are  stored.  We  assume  that  the  bulk  memory  device  is  a 
fixed-head  disk  with  rotational  position  sensing,  so  that  no  seek 
times  or  extra  rotations  are  incurred.  This  assumption  gives  a 
comparative  advantage  to  the  conventional  system  over  RAP  since 
most  data  bases  currently  reside  on  movable-head  rather  than 
fixed-head  devices. 


14 


The  time  to  retrieve  a  specific  tuple,  once  its  address  is 
known,  is  simply  half  a  disk  revolution  on  average  since  there  is 
no  seek  time  and  since  rotational  position  sensing  permits  access 
to  the  data  on  its  next  passage  past  the  read  mechanism.  We 
express  this  time  to  randomly  access  data  as: 

DATRAN  =  RTIME/2. 

Since  the  inverted  lists  are  located  using  the  hierarchical 
directory,  an  inverted  list  is  retrieved  with  two  separate  read 
operations.  First  the  appropriate  track  index  (as  determined  by 
directory  processing  in  main  memory)  is  read,  then  the  inverted 
list  itself  is  retrieved.  Thus  the  average  time  to  retrieve  an 
arbitrary  inverted  list  is: 

IV  RAN  =  2*RTIME/2  =  RTIME. 

Whenever  any  inverted  list  record  is  modified,  it  must  be 
read,  modified  in  main  memory,  then  re-written  on  the  following 
revolution.  The  average  time  for  accomplishing  this  is: 

IV  MOD  =  IV  RAN  +  RTIME  =  2*RTIME. 

The  impact  on  timing  of  overflow  in  the  indexed  sequential 
organization  of  the  inverted  list  files  will  be  considered  to  be 
a  second  order  effect  that  can  be  safely  omitted  from  this 
analysis. 

Next,  consider  the  amount  of  time  required  to  do  all  inverted 
list  processing  for  evaluating  a  qualification  expression.  Since 
inverted  list  processing  involves  comparisons  done  at  logic 
speeds,  the  only  significant  time  component  is  the  time  required 
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tc  transfer  the  necessary  inverted  lists  between  secondary 
storage  and  main  memory.  If  all  simple  conditions  in  the 
expression  are  tests  for  equality  (e.g.  egual-to  or  not-equal- 
to) ,  only  individual  inverted  lists  need  be  accessed.  However, 
some  or  all  comparisons  may  be  for  a  particular  inequality  (e.g. 
greater-than,  less-than,  etc.)  so  that  on  average  half  the 
inverted  file  must  be  read.  Again,  we  will  consider  only  the 
extreme  cases.  The  average  time  for  the  inverted  list  processing 
of  a  gualif ication  expression  is  given  by: 

fCL*IVRAN  if  all  comparisons  are  for  equality 
IVLIO  =  < 

[CL^SEQFET  (NTRIV/2)  if  all  comparisons  are  for  inequality 

where  NTRIV  is  the  number  of  tracks  occupied  on  average  by  an 
inverted  file  on  some  attribute.  Since  selection  in  the 
conventional  system  consists  precisely  of  the  inverted  list 
processing, 

SELCCN  =  IVLIC. 

However,  if  the  inverted  list  processing  required  for  some 
qualification  expression  is  too  extensive,  a  sequential  pass  over 
all  tuples  of  the  relation  may  be  faster.  In  such  a  case, 

S  EICON  =  SEQRET (#  T) 

where  #T  is  the  number  of  tracks  occupied  by  the  relation.  Both 
the  inverted  list  and  the  sequential  pass  versions  of  SELCON  will 
be  used  in  the  comparisons  in  section  V. 
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In  the  timing  formulae  above,  we  have  made  many  simplifying 
assumptions.  We  have  ignored  the  problem  of  track  overflow 
during  insertions.  We  have  considered  all  in-core  processing 
time  to  be  negligible.  Even  data  transfer  time  is  neglected. 
Finally,  the  necessity  of  occasionally  reorganizing  the  file  is 
not  accounted  for.  The  justifications  for  all  these  assumptions 
are  that  only  first-order  accuracy  is  being  attempted,  and  also 
that  a  more  detailed  study  [ 1  ]  has  shown  the  results  to  be 
insensitive  to  these  assumptions. 

V.  A  Comparison  of  RAP  Versus  Conventional  System  Operation  Times 

In  sections  III  and  IV,  we  derived  expressions  for  the 
average  time  to  do  selection  in  RAP  and  in  a  system  based  on 
conventional  hardware.  In  this  section,  we  will  use  those 
expressions  as  a  basis  for  estimating  the  timings  for 

1)  simple  retrieval, 

2)  update, 

3)  retrieval  based  on  a  functional  computation,  and 

4)  implicit  join. 

Table  1  summarizes  the  parameters  that  describe  the  hardware 
and  data  base  usage  characteristics.  Table  2  summarizes  the 
formulae  established  in  sections  III  and  IV. 

Through  the  calculations  below,  we  consistently  use  only 
average  values  for  all  relevant  variables  although  some  of  the 
variables  probably  have  distributions  with  high  variance.  For 
example,  the  number  of  occurrences  of  each  value  for  most 
attributes  probably  has  a  distribution  closer  to  geometric  than 
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to  uniform.  We  avoid  any  assumptions  about  the  distribution  by 
using  only  the  average.  This  approach  is  justified  because  the 
formulae  we  construct  as  final  results  are  calculations  of 
averages,  and  they  avoid  taking  products  between  dependent 
variables  (since  the  expectation  of  a  product  is  necessarily 
equal  to  the  product  of  the  expectations  only  if  the  variables 
are  independent) .  Also,  a  variety  of  experiments  with  more 
detailed  analytic  models  yielded  results  not  significantly 
different  from  those  obtained  here  [1]. 
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HARDWARE  PARAMETERS: 

RTIME  =  disk  revolution  time  in  the  conventional  system 
RAPRT I ME  =  revolution  (circulation)  time  for  RAP  memory 
k  =  number  of  comparator  units  in  each  RAP  cell 

DATA  EASE  SIZE  PARAMETERS: 

#C  =  average  number  of  cells  occupied  by  a  relation 
#P  =  average  number  of  tuple  position  per  cell 
NTRIV  =  average  number  of  tracks  occupied  by  an  inverted  list 
file  for  one  attribute  of  a  relation 
ND  =  average  number  of  inverted  domains  per  relation 
NP  =  average  number  of  occurrences  of  a  particular  value  for 
an  attribute 

QUERY  EEHAVIOUR  PARAMETERS: 

NR  =  average  number  cf  records  that  gualify  under  a 

gualif ication  expression 

CV  =  average  number  of  distinct  values  in  the  join  domain  of 
two  relations  being  joined 

Cl  =  average  number  of  simple  conditions  in  a  qualification 
expression 

OPS  =  average  number  of  arithmetic  operators  in  an  update 
expression 

Table  1 :  Model  Parameters 


RAP: 


QEVRAP 


[cL/kl 

[cL/2  + 


for  single-clause  expressions 
ij  for  multi-clause  expressions 


READOUT  (F)  =  expected  maximum  collision  length  at  any 

angular  position  on  RAP  if  fraction  F  of  the 
tuples  qualify  for  reading 
SELRAP  =  (.5  +  QEVRAP) *RAPRTIME 


CONVENTIONAL  SYSTEM: 


DATRAN  =  RTIME/2 

IVRAN  =  RTIME 

SEQRET(T)  =  (.5  +  T)*RTIME 

where  T  is  the  number  of  tracks  to  be  retrieved 


IVMOD  = 
IVLIO  = 
SELCON  = 


2*RTIME 

CL*I VRAN  for  equality  comparisons 

< 

^CL*SEQRET (NTRIV/2)  for  inequality  comparisons 
IVLIO 


Table  2:  Easic  Formulae 
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A.  Select  and  Betrieve 

First,  we  will  compare  the  performance  of  the  two  systems  on 
simple  retrieval  from  a  single  relation  where  the  qualification 
expression  does  not  include  any  functions.  In  both  systems,  a 
selection  is  followed  by  the  reading  of  the  qualified  tuples. 
Thus,  the  expected  average  simple  retrieval  times  in  BAP  and  in 
the  conventional  system  respectively  are: 

BETBAF  =  SELEAP  +  BEAEOUT  (NE) *BAPBTIME 
BETCON  =  SELCON  +  NE*DATEAN 

where  NH  is  the  number  of  tuples  that  qualify  for  selection. 

Figure  2  plots  the  ratio  of  BETCON/BETBAP  as  a  function  of 
the  number  of  tuples  retrieved  (NB)  for  various  parameter  values. 
The  curves  in  figures  2  to  5  are  all  based  on  the  following 
parameter  settings: 

k  =  5 

BAPBTIME  =  2.5*BTIME 
#C  =  100 

#P  =  1000 

(Therefore,  there  are  100,000  tuples.) 

"Eest  case"  and  "worst  case"  selection  in  figure  2  (and 
figures  3,  4  and  5)  refer  respectively  to  qualification 

expressions  which  are  equality  and  single-clause  or  inequality 
and  multi-clause.  While  little  empirical  evidence  is  available, 
it  appears  that  equality  comparisons  and  single-clause 

expressions  are  the  more  common  case  in  practice. 
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Figure  2  Simple  retrievals 
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The  solid  curves  show  that  RAP's  advantage  grows  in  almost 
direct  proportion  to  the  number  of  records  satisfying  the 
qualification  when  inverted  lists  are  used  in  the  conventional 
system.  The  advantage  is  greatest  for  the  simplest 
qualification,  which  is  just  a  single  simple  condition.  When 
CL=10,  RAP's  advantage  is  greater  for  best  case  selection 
expressions  than  for  worst  case  selection  expressions.  The 
dashed  curves  represent  the  situation  where  the  conventional 
system  ignores  the  inverted  lists  and  simply  scans  the  entire 
file  (i.e.,  using  the  second  version  of  SELCON  from  section  IV). 
Naturally,  RAP's  advantage  here  diminishes  as  the  number  of 
qualified  tuples  increases.  The  intersection  of  a  dashed  curve 
with  a  corresponding  solid  curve  indicates  the  break-even  point 
between  the  two  possible  approaches  in  the  conventional  system, 
and  also  the  point  at  which  RAP's  gain  reaches  a  maximum  (of  from 
80  to  160  approximately).  With  the  parameter  value  settings 
assumed  here,  this  occurs  with  between  1%  and  3%  of  the  tuples 
qualifying.  Tests  with  other  parameter  values  have  shown  that 
the  shapes  and  magnitudes  of  these  curves  are  not  sensitive  to 
file  size  (number  of  tuples  in  a  relation)  or  to  the  average 
number  of  distinct  values  for  an  attribute  (NP) .  Assuming 
movable-head  rather  than  fixed-head  disks  for  supporting  the 
conventional  system,  tests  reveal  that  RAP's  advantage  is 
increased  by  40%  to  90%  within  the  range  of  NR  shown  in  the 
figures. 
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E.  Select  and  Update 

This  operation  consists  of  selecting  a  set  of  tuples  with  a 
qualification  expression  then  updating  the  selected  tuples. 
Updates  are  considered  to  include  insertions  and  deletions  of 
tuples  as  well  as  modifications  of  tuples. 

Consider  first  modifications  in  the  conventional  system. 
After  the  set  of  tuples  to  be  modified  is  selected  (in  time 
SELCON) ,  each  of  the  NR  qualified  records  must  be  read,  modified, 
and  re-written  (in  time  NR*(DATRAN  +  RTIME)).  Finally,  if  the 
modified  attribute  is  inverted,  then  two  inverted  list 
alterations  (removal  of  a  pointer  from  one  list  and  insertion 
into  another)  are  required.  This  requires  on  average  NR*2*IVM0D 
time.  Thus,  the  average  time  to  do  selection  and  modification  in 
the  conventional  system  is: 

MODCON  =  SELCON  NR*  1 . 5*RTIM  E  +  NR*2*IVM0D. 

In  the  RAF  system,  selection  and  a  simple  modification  can  be 
done  simultaneously  in  one  revolution.  Only  if  the  modification 
expression  involves  more  than  one  arithmetic  operator  will 
additional  revolutions  (one  for  each  additional  operator)  be 
required.  Thus: 

MCCRAP  =  SE1RAP  +  (OPS  -  1) * RAP RTIME 

where  OPS  is  the  number  of  arithmetic  operators  in  the  update 
expression.  (Simple  replacement  counts  as  one  arithmetic 
operation.)  Note  that  the  marginal  cost  of  updating  additional 
inverted  attributes  after  the  first  is  only  NR*2*IVM0D  per 
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additional  attribute  in  the  conventional  system  and  an  additional 
revolution  in  the  BAP  system. 

When  the  update  involves  deletion  rather  than  modification, 
the  timing  in  the  conventional  system  changes  only  in  that  an 
inverted  list  modification  is  reguired  to  remove  the  pointer  to 
the  tuple  being  deleted  from  the  appropriate  inverted  list.  In 
BAP,  selection  and  deletion  is  accomplished  in  the  same  time  as 
selection  itself  since  tuples  are  simply  flagged,  and  then 
automatically  removed  later  by  the  garbage  collection  scheme. 
The  deletion  formulae  are: 

DELCON  =  SELCON  ♦  NB*  (1 .5*BTIME  +  ND*IVMOD) 

where  ND  is  the  number  of  inverted  attributes  and 
NB  is  the  number  of  tuples  deleted 

DEIBAP  =  SELCON. 

Insertions  involve  no  selection.  In  a  conventional  system, 
the  tuples  are  simply  inserted,  then,  for  each  inverted  domain, 
an  addition  to  the  appropriate  inverted  list  is  made.  In  BAP, 
the  addition  of  a  single  tuple  is  completed  in  a  single 
revolution.  (In  the  occasional  instances  where  all  cells  are 
full,  an  extra  revolution  is  required  to  format  a  new  cell.)  Bulk 
insertions  are  handled  in  a  different  way,  so  that  many  tuples 
may  be  added  in  a  single  revolution  [1].  The  timing  formulae 
are : 

INSCON  =  NB* ( 1 . 5*  BTIM  E  +  ND*IVMOD) 

fNB*BAPBTIME  for  individual  insertions 

BAPBTIME  for  bulk  insertions 
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Figure  3  graphs  the  ratio  MODCON/MODRAP  as  a  function  of  NR, 
the  number  of  tuples  updated,  for  various  combinations  of 
qualification  structures  and  parameter  values  for  OPS  and  CL. 
The  solid  curves  reflect  queries  with  single  clauses  and  equality 
tests  ("best  case")  while  the  dashed  curves  correspond  to  queries 
of  more  complex  structure  (multi-clause  and  inequality  tests,  or 
"worst  case").  Increased  qualification  complexity  reduces  RAP’s 
relative  performance  advantage  since  extra  revolutions  may  be 
required  for  selection. 

As  the  number  of  simple  conditions  (CL)  increases,  RAP’s 
relative  advantage  decreases  since  it  incurs  extra  revolutions, 
while  in  the  conventional  system,  part  of  the  extra  work  is  done 
at  main  memory  speed.  As  the  complexity  of  the  update  expression 
(CPS)  grows,  RAP’s  relative  advantage  again  decreases  for  the 
same  reason.  The  general  steepness  of  the  slopes  and  magnitudes 
of  the  ratios  reflect  the  high  price  paid  in  a  conventional 
system  for  maintaining  fast  access  paths. 

C.  Select,  Compute  Function  and  Retrieve 

This  operation  retrieves  tuples  only  from  a  single  relation, 
but  the  qualification  expression  contains  a  function  which  must 
first  be  computed  over  a  subset  of  the  tuples.  For  example,  one 
might  wish  to  list  all  those  employees  that  have  a  salary  higher 
than  the  minimum  salary  of  any  vice-president  in  the  company. 
Such  a  guery  would  be  handled  as  follows: 

1)  select  all  vice-presidents, 

2)  compute  the  minimum  of  their  salaries. 


UPDATE  RATIO  (MODCON/MOURAP ) 


Best  case  selection 


NUMBER  UPDATED  (UR) 


Figure  3.  Updates 
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3)  select  all  employees  with  a  salary  greater  than  the 

minimum  chosen  in  (2) , 

4)  retrieve  the  tuples  selected  in  (3) . 

In  the  conventional  system,  inverted  list  processing  must  be 
done  first  on  title  (to  get  all  the  vice-presidents)  then  later 
on  salary  (to  get  all  employees  with  sufficiently  high  salaries) . 
The  records  corresponding  to  either  of  these  must  be  retrieved. 
Thus  the  average  time  for  the  entire  operation  is: 

FRETCON  =  2*SELC0N  +  (FNS  ♦  NE) *DATRAN 

where  FNS  and  NE  are  the  numbers  of  tuples  selected  by  the 
function  qualification  and  the  selection  qualification 
respectively. 

The  timing  on  EAP  is  the  same  as  for  simple  retrieval  except 
that  the  function  must  be  calculated  first.  Since  the  time  to  do 
most  functions  is  one  revolution  (AVERAGE  takes  two) , 

FEETEAP  =  EAPETI ME  +  EETEAP 

=  EAPETIME  +  SELEAP  +  EEADOOT(NE) *RAPRTIME. 

Figure  4  graphs  FEETCON/FRETEAP  as  a  function  of  NR.  We  can 
observe  that  RAP's  advantage  is  maximized  when  the  size  of  the 
tuple  set  on  which  the  function  is  based  (FNS)  is  larger  rather 
than  smaller.  The  ratio  is  so  large  when  many  tuples  are 
involved  in  the  function  computation  that  this  operation  may  be 
prohibitively  expensive  in  a  conventional  system. 

Note  that,  at  low  responder  volume  (small  NE) ,  the  number  of 
tuples  involved  in  the  function  computation  determines  whether 
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Figure  4 


Select  &  compute  function  &  retrieve 
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equality  or  inequality  comparisons  lead  to  the  larger  RAP 
advantage.  The  reason  for  this  is  again  the  fact  that  when 
enough  records  are  to  be  examined,  the  most  economical  approach 
for  the  conventional  system  is  to  process  all  tuples  sequentially 
rather  than  use  inverted  lists. 

D.  Cross  Retrieval 

This  operation  uses  a  (previous)  selection  of  tuples  from  one 
relation  as  a  basis  for  selecting  and  subsequently  retrieving 
tuples  from  another  relation.  The  relations  involved  must  have 
attributes  with  values  from  a  common  domain.  These  attributes 
will  be  referred  to  as  the  join  attributes  of  respectively  the 
source  and  target  relations.  Cross  retrieval  can  be  generalized 
to  include  several  relations  by  using  each  in  turn  as  the  basis 
for  selecting  tuples  from  the  next. 

The  procedure  for  accomplishing  cross  retrieval  in  the 
conventional  system  consists  of  the  following: 

1)  Selection  on  the  source  relation  to  produce  a  selected 
pointer  list. 

2)  Sequential  retrieval  of  each  inverted  list  for  the  join 
attribute  of  the  source  relation. 

3)  Matching  (in  main  memory)  of  the  sets  of  pointers  acquired 
in  (1)  and  (2)  to  produce  the  set  of  join  attribute  values 
for  which  a  pointer  in  the  first  set  matches  a  pointer  in  the 
second  set  (called  the  implicit  join  criteria  list) . 

4)  For  each  value  in  the  set  of  (3) ,  retrieve  the  inverted 
list  for  the  join  attribute  of  the  target  relation. 
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5)  Merge  (in  main  memory)  the  pointer  lists  obtained  in  (4) 
eliminating  duplicates. 

6)  For  each  pointer  in  the  list  resulting  from  (5)  retrieve 
the  tuple  from  the  target  relation. 

When  more  than  two  relations  are  involved,  steps  1  to  5  are 
repeated  for  each  relation  except  the  final  target  relation. 

In  the  case  of  two  relations,  the  average  time  to  complete 
cress  retrieval  is: 

CBSCON  =  SELCON  +  SEQBET  (NTEIV)  +  CV*BANBET  +  NB*DATBAN 

where  CV  is  the  number  of  distinct  values  in  the  implicit 
join  criteria  list  (obtained  in  step  (3)). 

The  four  terms  in  the  expression  correspond  to  steps  1,  2,  4, 
and  6  respectively.  If  CV  is  large  relative  to  the  total  number 
of  distinct  values  for  the  join  attribute  in  the  target  relation, 
then  step  4  might  be  more  efficiently  done  by  retrieving  the 
entire  inverted  file  sequentially. 

In  BAP,  cross  retrieval  is  performed  much  the  same  as  in  the 
conventional  system.  First,  selection  on  the  source  relation  is 
done,  then  cross-marking  to  the  target  relation  accomplishes  the 
implicit  join.  Finally,  readout  of  the  qualified  target  relation 
tuples  is  required.  In  BAP,  however,  the  process  can  be  speeded 
up  by  a  separate  operation  to  eliminate  duplicate  values  in  the 
implicit  join  criteria  list  (unless  the  source  join  attribute  is 
a  key,  i.e.,  a  candidate  key,  [5]  sc  that  all  values  are  unique). 
This  operation,  is  projection  and  can  be  performed  before  cross- 
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marking.  It  is  accomplished  by  an  iterated  GET_FIRST_MARK 
instruction  which  picks  up  join  attribute  values  in  turn  and 
unmarks  all  other  tuples  containing  the  same  value. 

The  cross-marking  would  be  achieved  successfully  with  the 
same  result  if  the  projection  were  not  included.  However,  the 
cross-mark  would  reguire  more  revolutions  since  each  occurrence 
of  each  value  in  the  join  domain  would  be  treated  separately  in 
the  cross-marking.  That  is,  much  work  would  be  repeated.  As  a 
rule,  doing  projection  reduces  total  operation  time  if  and  only 
if  the  average  number  of  occurrences  of  each  join  attribute  value 
in  selected  source  tuples  exceeds  k,  the  number  of  comparator 
units  on  each  cell.  Obviously,  if  the  join  attribute  is  a  key 
for  the  source  relation  (i.e.  no  duplicates)  the  projection  saves 
nothing,  yet  requires  one  revolution  for  each  selected  source 
tuple . 

The  average  time  for  RAP  to  do  cross  retrieval  if  projection 
is  included  is: 

CRSPRAP  =  SELRAP  +  (CV  +  #C)*RAPRTIME  +  (1  +  CV/k  +  #C)*RAPRTIME  + 
READOUT (NR) *RAPRTIME 

The  four  terms  correspond  to  selection,  projection,  cross- mark 
and  readout.  The  parameter  #C  appearing  in  the  second  and  third 
terms  reflect  the  delay  incurred  by  RAP  in  scanning  for  the  next 
value  (or  value  set)  to  apply  in  either  projection  or  cross¬ 
marking.  At  worst,  this  scanning  totals  to  one  revolution  for 
each  cell  occupied  by  the  selected  tuples  of  the  source  relation. 
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If  the  projection  is  not  done  (as  for  source  relation  join 
attributes  which  are  keys) ,  the  second  term  disappears.  This 
alters  the  formula  for  CRSRAP  to: 

CRSRAP  =  SELRAP  +  (1  +  CV/k  +  #C) *RAPRTIME  + 

READOUT (NR) *RAPRTIME 

Figure  5  indicates  the  relative  performance  of  RAP  and  a 
ccnventional  system  for  cress  retrieval.  In  addition  to 
parameters  involved  in  the  earlier  comparisons,  there  are  some 
other  considerations  with  cross  retrieval: 

1)  variation  of  file  sizes  between  source  and  target 
relations, 

2)  variation  of  the  average  number  of  occurrences  of  each 
attribute  value  between  the  source  and  target  join 
attributes , 

3)  the  proportion  of  value  matches  between  the  implicit  join 
criteria  list  and  the  join  attribute  of  the  target  relation. 

However,  calculations  indicate  that  the  results  shown  in  figure  5 
are  insensitive  to  variations  in  these  additional  parameters. 
The  number  of  relations  involved  in  the  cross  retrieval  (NRL) 
does  not  significantly  change  the  curves  of  figure  5,  although 
larger  numbers  increase  RAP's  advantage  slightly. 

The  most  influential  consideration  in  the  relative 
performances  of  RAP  and  the  conventional  system  is  whether  or  not 
the  join  attribute  is  a  key  of  the  source  relation.  If  so, 
projection  is  avoided  and  RAP's  advantage  is  substantial  when  the 
number  of  tuples  finally  retrieved  is  small.  If  not,  the  number 


RETRIEVAL  RATION  (CRSCON/ (CRSRAP  or  CRSPRAP)) 


2.0 


i  Worst  case  selection 
\NRL=2  r  3,  NP=100 
1.6  \ 

\ 

Worst  case  selection 
\  V  NRL=2,  NP=200 
\  ' 

1.2  '  ' 


NON -KEY 


0.8 


Best  case  selection 
NRL=2  s  3,  NP-100 

'  r  - 


0.4  Best  case  selection 
NRL=2.  NP=200 


500  1000  1500  2000  2500 

NUMBER  OF  RESPONDERS  (NR) 


3000 


Figure  5 


Cross  retrievals 


29 


of  revolutions  required  in  the  two  systems  is  essentially  the 
same  (except  that  RAP  takes  fewer  when  the  number  of  tuples 
retrieved  is  small) .  Since  the  conventional  system  is  presumed 
to  have  a  disk  that  revolves  2.5  times  faster  than  RAP,  cross 
retrieval  cn  a  non-key  source  relation  attribute  where  a  large 
number  of  tuples  are  finally  retrieved  is  a  situation  where  the 
conventional  system  takes  noticably  less  time  than  RAP.  However, 
the  difference  only  reaches  a  factor  of  2.5  when  the  conventional 
system  uses  a  fixed-head  disk.  The  use  of  a  movable-head  disk 
would  approximately  cancel  the  conventional  system's  advantage. 
Also,  in  the  non-key  cross  retrievals,  it  was  assumed  that  the 
average  number  of  occurrences  of  each  join  domain  value  (NP)  is 
100  or  200.  If,  in  fact,  this  number  were  smaller  (approaching 
N P= 1  for  key  domains),  RAP's  advantage  would  be  greater. 

Since  selection  accounts  for  only  a  small  portion  cf  cross 
retrieval  time,  the  effects  of  qualification  structure  and  the 
number  of  simple  conditions  are  small. 

VI.  Conclusions 

A  comparative  performance  evaluation  between  models  of  RAP 
and  a  conventional  implementation  of  a  relational  data  base 
management  system  have  been  presented.  General  first-order 
analytical  models  were  developed  for  each  system.  Basic 
relational  BEMS  operations,  which  are  taken  as  the  basis  of 
comparisons,  were  formulated  with  respect  to  these  models. 
Curves  showing  the  relative  average  operation  times  were  plotted. 
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The  results  show  that  the  advantages  of  associative 
processors  in  supporting  data  base  management  systems  are  very 
significant,  as  was  also  shown  by  previous  studies  [11,12]. 


Conventional 

systems  have  to 

pay  a 

very  high  price 

in 

terms 

of 

the  extra 

software  and 

data 

required  for 

providing 

and 

maintaining 

fast  access  mechanisms. 

This  difficulty 

makes 

the 

design  of  generalized  data  base  management  systems  very  hard.  A 
system  tuned  for  retrieval  will  suffer  in  update  time  and  vice 
versa.  In  this  study,  with  the  exception  of  comparisons 
involving  sequential  scans  of  relations,  it  was  assumed  that  the 
conventional  system  is  designed  for  a  good  overall  performance 
and  that  there  are  a  high  percentage  of  indexed  domains 
sufficient  for  all  the  queries  encountered.  Despite  these 
assumptions,  it  is  seen  that  PAP  totally  outperforms  the 
conventional  system.  The  ratios  are  so  large  that  the  choice  of 
particular  access  paths  and  file  access  strategies  does  not  have 
a  significant  effect.  Also,  throughout  the  model,  assumptions 
were  consistently  made  to  favor  the  conventional  system.  Since  a 
high  proportion  of  cross  retrievals  are  expected  to  involve  join 
attributes  that  are  keys,  implicit  joins  will  also  be  performed 
better  by  RAP  than  by  the  conventional  system.  Under  some 
circumstances,  on-line  updating  of  large  data  bases  may  only 
become  feasible  with  the  aid  of  RAP-like  devices. 

Associative  memories  eliminate  indexing,  and  thus  eliminate 
links  or  pointers  needed  for  establishing  access  paths.  RAP  is  a 
processor  that  utilizes  these  features  of  associative  memories 
and  proves  to  be  a  solution  to  many  of  the  problems  of  supporting 
modern  data  base  management  systems. 
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